Dynomotion

Group: DynoMotion Message: 11637 From: Hardy Family Date: 6/4/2015
Subject: G-code with unix line endings not working
Using KMotion-CNC 4.32, I can single step through the following code copied over from Unix (i.e. with \n line endings not \r\n):

M98 P111
M2

O111
M98 P220
M99

O220
M99

but if I run it using the cycle start button then it says "bad character used" on the 2nd last M99.  All sorts of other random errors if things are moved around e.g. if I get rid of the blank lines, then cycle start will spin it into an infinite loop.

If the exact same code is entered in Windows, it works fine.  [Oh curse Microsoft for ever deviating from the one true line ending convention! In the days of 100k floppies, why would anyone decide to use 2 chars when one would do?]

Regards,
SJH
Group: DynoMotion Message: 11639 From: Jeremy Brown Date: 6/5/2015
Subject: Re: G-code with unix line endings not working

Here’s why \r\n instead of only \n (the best answer I could find):

 

Backward compatibility.

 

Windows is backward compatible with MS-DOS (aggressively so, even) and MS-DOS used the CR-LF convention because MS-DOS was compatible with CP/M-80 (somewhat by accident) which used the CR-LF convention because that was how you drove a printer (because printers were originally computer controlled typewriters).

 

Printers have a separate command to move the paper up one line to a new line, and a separate command for returning the carriage (where the paper was mounted) back to the left margin.

 

That's why. And, yes, it is an annoyance, but it is part of the package deal that allowed MS-DOS to win over CP/M, and Windows 95 to win over all the other GUI's on top of DOS, and Windows XP to take over from Windows 98.

 

(Note: Modern laser printers still have these commands because they too are backwards compatible with earlier printers - HP in particular do this well)

 

Ah, the blessings of backward compatibility.

Jeremy

 

Group: DynoMotion Message: 11640 From: Hardy Family Date: 6/5/2015
Subject: Re: G-code with unix line endings not working
Ah yes, teletype compatibility.

Getting off-topic here, but it really reflects badly on the software industry: how (I ask rhetorically) could it have been so hard to have the computer read each line of the file to be printed, and translate \n to \r\n.  Nobody, and I mean no sane person, wants \n to just roll the platen down to the next line without returning the carriage.

CP/M was an excellent OS for the time, but really, guys... :-)


On Fri, Jun 5, 2015 at 9:49 AM, Jeremy Brown jeremy@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Here’s why \r\n instead of only \n (the best answer I could find):

 

Backward compatibility.

 

Windows is backward compatible with MS-DOS (aggressively so, even) and MS-DOS used the CR-LF convention because MS-DOS was compatible with CP/M-80 (somewhat by accident) which used the CR-LF convention because that was how you drove a printer (because printers were originally computer controlled typewriters).

 

Printers have a separate command to move the paper up one line to a new line, and a separate command for returning the carriage (where the paper was mounted) back to the left margin.

 

That's why. And, yes, it is an annoyance, but it is part of the package deal that allowed MS-DOS to win over CP/M, and Windows 95 to win over all the other GUI's on top of DOS, and Windows XP to take over from Windows 98.

 

(Note: Modern laser printers still have these commands because they too are backwards compatible with earlier printers - HP in particular do this well)

 

Ah, the blessings of backward compatibility.

Jeremy

 

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, June 4, 2015 5:28 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] G-code with unix line endings not working

 

 

Using KMotion-CNC 4.32, I can single step through the following code copied over from Unix (i.e. with \n line endings not \r\n):


M98 P111
M2

O111
M98 P220
M99

O220
M99

but if I run it using the cycle start button then it says "bad character used" on the 2nd last M99.  All sorts of other random errors if things are moved around e.g. if I get rid of the blank lines, then cycle start will spin it into an infinite loop.

If the exact same code is entered in Windows, it works fine.  [Oh curse Microsoft for ever deviating from the one true line ending convention! In the days of 100k floppies, why would anyone decide to use 2 chars when one would do?]

Regards,

SJH
Group: DynoMotion Message: 11650 From: Tom Kerekes Date: 6/5/2015
Subject: Re: G-code with unix line endings not working
Hi SJH,

Looks like a couple line change to the interpreter to strip off any additional CR or LF at the end of the line should solve this problem.

I have some code to try.  Can you attach a file that shows a problem?

Regards
TK

Group: DynoMotion Message: 11655 From: Hardy Family Date: 6/6/2015
Subject: Re: G-code with unix line endings not working
Attachments :
Hi Tom,

Here's some sample code.

Regards,
SJH


On Fri, Jun 5, 2015 at 7:25 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Looks like a couple line change to the interpreter to strip off any additional CR or LF at the end of the line should solve this problem.

I have some code to try.  Can you attach a file that shows a problem?

Regards
TK

Group: DynoMotion Message: 11656 From: Tom Kerekes Date: 6/6/2015
Subject: Re: G-code with unix line endings not working [1 Attachment]
Hi SJH,

It seems the problem actually was that fgetpos and fsetpos just don't work correctly with files in text mode without CR+LF in them.  If the file position is obtained and then the file is set to that position it ends up somewhere else.

Opening in binary mode seems to fix the problem.  Attached is a source file with the changes based from V4.33l.  Please test it and let us know if you find any issues.

Regards
TK

Group: DynoMotion Message: 11665 From: Hardy Family Date: 6/8/2015
Subject: Re: G-code with unix line endings not working [1 Attachment]
Hi Tom,

I there a release KMotionCNC.exe built using that change?  I only have Visual C 2013 so I would have to go through the process of upgrading the solution files and other tweaks outlined in the other discussion.  I can do that, but I am not sure that it wouldn't be introducing some other unknowns.

On a related subject, when do you expect to have an official (stable?) 4.33 version available?  We are currently developing based on 4.32 but because of the TCC fix etc. and improvements to KMotionCNC we would rather release our controllers with 4.33.  Should we go with 4.33L?

At some stage I would like to merge all 433 changes with the Linux port, which is currently based off 432, so I am waiting for a reasonably stable point to do that.

Regards,
SJH


On Sat, Jun 6, 2015 at 11:23 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 
[Attachment(s) from Tom Kerekes included below]

Hi SJH,

It seems the problem actually was that fgetpos and fsetpos just don't work correctly with files in text mode without CR+LF in them.  If the file position is obtained and then the file is set to that position it ends up somewhere else.

Opening in binary mode seems to fix the problem.  Attached is a source file with the changes based from V4.33l.  Please test it and let us know if you find any issues.

Regards
TK

Group: DynoMotion Message: 11674 From: Tom Kerekes Date: 6/10/2015
Subject: Re: G-code with unix line endings not working
Hi SJH,

No we don't have a binary with that change.  It would be in the GCodeInterpreter.dll btw.  Of course the workaround is to simply change the line endings.

Yes we hope to release 4.33 soon with only minor fixes from Test Version 4.33l.  We'd appreciate if you develop with Test Release 4.33l and let us know if there are any issues before we release 4.33.

Regards
TK

Group: DynoMotion Message: 11675 From: Hardy Family Date: 6/10/2015
Subject: Re: G-code with unix line endings not working
No problem.  We have migrated to 433L and doing all our development and testing on it.

Since there's no binary, I'll have to defer the line ending test until I get a change to build the app.  We're getting ready for release ourselves, and anticipate having to build the app to get our 5-axis kinematics in and tested.  That should be a few weeks from now.

Regards,
SJH


On Wed, Jun 10, 2015 at 5:59 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

No we don't have a binary with that change.  It would be in the GCodeInterpreter.dll btw.  Of course the workaround is to simply change the line endings.

Yes we hope to release 4.33 soon with only minor fixes from Test Version 4.33l.  We'd appreciate if you develop with Test Release 4.33l and let us know if there are any issues before we release 4.33.

Regards
TK